Next | Prev | Up | Top | Contents | Index
Compatibility and Supported ABIs
With the IRIX 6.2 release on an R8000 system, you can execute programs conforming to any of the following Application Binary Interfaces (ABIs):
- An o32 program built under IRIX 5.x or IRIX 6.2 (32-bit MIPS1 or MIPS2 ABI).
- A 64-bit program built under IRIX 6.1 or IRIX 6.2 (64-bit MIPS3 or MIPS4 ABI).
- An N32 program built under IRIX 6.2 (N32 MIPS3 or MIPS4 ABI).
Figure 1-1 illustrates the ABIs supported by IRIX 6.2.
[Missing image]
Figure 1-1 : ABIs supported by IRIX 6.2
More specifically, the execution and development environments under IRIX 6.2 provide the following functionality:
- 32-bit IRIX 5.x binaries and Dynamic Shared Objects (DSOs) execute under IRIX 6.2
- IRIX 6.2 has a set of compilers (32-bit Native Development Environment) that generate 32-bit code. You can mix objects and link with objects produced on IRIX 5.x. (We do not, however, guarantee that this code runs on current IRIX 5.x systems.)
For this release, this set of compilers is, in fact, the same (with minor modifications) ucode compilers shipped on current IRIX 5.x systems.
- IRIX 6.2 also has a set of compilers (64-bit Native Development Environment) that generates either 64-bit or N32 code. This code cannot run on current IRIX 5.x systems.
- You can specify which compiler you want to run by using the -64, -n32 or -32 flags on the compiler command line.
The compiler driver then executes the appropriate compiler binaries and links with the correct libraries. This also applies to the assembler, linker, and archiver. If these switches are not present, the driver checks an environment variable, SGI_ABI, for these values.
The default under IRIX 6.2 is -64 for R8000 systems and -32 for R4x00 systems.
- All of the compiler-related tools (dbx, nm, dis, pixie, prof) except pixstats can work with either 32-bit, N32 or 64-bit binaries. pixstats functionality for 64-bit programs is integrated into prof.
- You cannot mix objects and DSOs produced by the 32-bit compilers with objects and DSOs produced by the 64-bit compilers. In Figure 1-1, this is illustrated by the lines separating the 32-bit, N32 and 64-bit libraries.
This means:
- You cannot link 32-bit objects with 64-bit or N32 objects and shared libraries
- You cannot link 64-bit objects with 32-bit or N32 objects and shared libraries
- You cannot link N32 objects with 64-bit or 32-bit objects and shared libraries
- The /usr/lib directory on IRIX 6.2 contains the 32-bit libraries and .sos. The 64-bit .sos are located in /usr/lib64. The N32 .sos are located in /usr/lib32. The complete layout looks like this:
32-bit: This is the IRIX 5.x /usr/lib, including compiler components:
/usr/lib/
*.so
mips2/
*.so
/usr/lib/
cfe
fcom
ugen
uopt
as
64-bit: These are the 64-bit-specific components:
/usr/lib64/
*.so
mips3/
*.so
mips4/
*.so
/usr/lib64/cmplrs
be
fec
fef77
fef90
as
N32: These are the N32-specific components:
/usr/lib32/
*.so
mips3/
*.so
mips4/
*.so
Known Compatibility Issues
The following issues are known to cause trouble for 32-bit programs running on IRIX 6.2:
- Any access to kernel data structures, for example, through /dev/kmem. Many of these structures have changed in size. Programs making these kinds of accesses must be ported to 64-bit. 32-bit programs cannot access all of kernel memory, hence probably must also be ported to 64-bit.
- Use of nlist() does not work on any 64-bit .o or a.out. A new nlist64() is supplied for 64-bit ELF.
- Any assumption that the page size is 4Kbytes (for example, using mmap() and specifying the address). The page size is no longer 4Kbytes. Programs must use getpagesize().
- Ada programs which catch floating point exceptions do not work.
- Any program using /proc must have some interfaces changed.
It is possible for a program to determine whether it is running on a 64-bit capable kernel in order to work around the issues listed above. Use sysconf(_SC_KERN_POINTERS), which returns 32 or 64.
Source Level System Interface
The IRIX APIs, as defined in SVID and POSIX, are unchanged. Source code requires no changes to be built -64. The compiled bit sizes of arguments and fields may indeed be different between the 32-bit and 64-bit definitions, but source code should not have to be changed. For example, off_t and size_t are now 64 bits when compiled -64 and 32 bits when compiled -32.
The source code interface to IRIX therefore remains the same, with a few exceptions. This interface is defined by the set of header files in /usr/include. Most of these header files have not changed. The kernel maintains compatibility by converting all system calls from a 32-bit binary into 64-bit internal kernel format. The kernel maintains all states in a superset form (usually 64 bits), converting data structures upon entry to and exit from the kernel. As a result, the kernel continues to keep traditional IRIX form and state information of processes, files, and other structures.
Graphics Environment Support
Table 1-1 summarizes the graphics environments supported under IRIX 6.2. Basically, all of the graphics environments are provided for 32-bit, N32 and 64-bit applications.
IRIX 6.2 Graphics Environment Support
| Package | 32-bit Support | 64-bit Support | N32 Support |
|---|
| IRIX GL (libgl) | Yes | Yes | Yes |
| OpenGL | Yes | Yes | Yes |
| X11R6 | Yes | Yes | Yes |
| Motif1.2.4 | Yes | Yes | Yes |
Inter-Process Communication
Interfaces across a network connection usually allow 32-bit and 64-bit programs to communicate (for example, NFS works fine). Programs using RPC and XDR should have no problems. Of course, exchanging binary data with size assumptions which do not agree can fail.
Usually, there are no problems with having 32-bit and 64-bit programs interact via system calls. For instance, sending data through a pipe, or sharing file access, or connecting through the network, or shared memory usage, all work. In all cases, however, binary data structure sizes must agree.
Arenas are an exception (see usinit(3)). They are not compatible between 32-bit and 64-bit programs. Arenas can be used within a set of 32-bit programs, and within a set of 64-bit programs, but not across program types. See test_and_set(3) and abilock(3) for locks compatible with 32-bit and 64-bit programs.
Device Driver Interface
The IRIX 6.2 kernel requires MIPS3 or MIPS4 code. MIPS1 drivers cannot be linked. Additionally, the kernel is now linked in ELF format, so the -coff option to link 5.x drivers is no longer used.
The kernel/driver interface (DDI/DKI) has a few changes and some additions. Usually kernel drivers need a lot of rework due to internal assumptions of pointer sizes, page sizes, and I/O mapping sizes.
Socket ioctl() calls to the kernel by 32-bit programs are converted for socket ioctls automatically. Hence, whether a 32-bit or 64-bit program is doing the call makes no difference to the kernel.
Block and character drivers have to be responsible for their own ioctls(). The approach which IRIX drivers follow is to have a single header file for user code compilation, so the driver must convert fields according to differences between the 32-bit and 64-bit compilation models.
For streams, the driver will not know the user process type, so ioctls must be fixed binary data structures. They cannot vary between the 32-bit or 64-bit compilation models. You must fix your header files such that this is true.
Routines have been added to the device kernel interface (DKI) to aid ioctl conversions. Please refer to the IRIX Device Driver Writer's Guide.
Next | Prev | Up | Top | Contents | Index